Database consolidation involves distributing and sharing computing resources among multiple databases managed by one or more database servers of database management systems (DBMS). Databases may be consolidated using a container DBMS. A consolidated database, such as a multitenant container database (CDB), includes one or more pluggable databases (PDBs). In a container DBMS, each pluggable database may be open or closed in the container database independently from other pluggable databases.
Pluggable databases may be “plugged in” to a container database, and may be transported between database servers and/or DBMSs. The container DBMS may manage multiple pluggable databases and a given database server instance may serve those pluggable databases from the container database. As such, a given container database allows multiple pluggable databases to run on the same database server and/or database server instance, allowing the computing resources of a single database server or instance to be shared between multiple pluggable databases.
An application may access a pluggable database by establishing a database session on the container DBMS for that pluggable database, where a database session represents the connection between an application and the container DBMS for accessing the pluggable database. A database session is initiated for a pluggable database by, for example, transmitting a request for a new connection to the container DBMS, the request specifying the pluggable database. A container DBMS may host multiple database sessions, each database session being for one of multiple pluggable databases.
One of the big advantages of container database architecture is the ability to provision new databases quickly.
Moving a PDB between container databases presents various problems. For example, moving the data for a PDB from a source CDB to a destination CDB can take a significant amount of time (i.e., on the order of days for very large PDBs). It is also costly to make a PDB unavailable for the duration of moving the PDB. Also, relocating a PDB to a destination CDB can be disruptive to users that use data from the PDB at the source CDB.
Generally, moving the files for a PDB between container DBMSs may be accomplished in multiple ways, including: copying the files to an external hard drive and physically moving the hard drive to the location of the destination storage, setting up an auxiliary DBMS that leverages replication to synchronize changes across container databases, and live migration of virtual machines from one physical server to another.
The architecture of a container DBMS greatly facilitates transporting databases between database servers and/or DBMSs. Tablespace files and a data dictionary store may be moved between environments of container DBMSs using readily available mechanisms for copying and moving files. The tablespace files, along with one or more dictionary files, are referred to herein collectively as a transportable database package. However, a transportable database package is a logical set of loose files, which may be difficult to identify and manage.
Once the transportable database package of a pluggable database is moved to the environment of the target container DBMS, the pluggable database can be plugged into the target container DBMS. In an embodiment, plugging in the pluggable database is performed in response to receiving a DDL command to plug in the pluggable database, the DDL command also identifying the transportable database package. In response to receiving the DDL command, the container DBMS plugs in the pluggable database. Plugging in the pluggable database entails such operations as updating a root database dictionary to define the pluggable database, such updates including, for example, adding a record to a metadata table. Error checking is also performed. For example, checks are performed to ensure that the name of the pluggable database is unique within the container DBMS and that tablespace files are not already being used for other tablespaces in the container DBMS.
A container DBMS provides advantages for database consolidation. Among such advantages is providing a high degree of isolation concurrently along with a high degree of resource sharing. Multiple pluggable databases may run on the same database server and/or database server instance, allowing the computing resources of a single database server or instance to be shared between multiple pluggable databases.
However, copying and moving pluggable databases may introduce complexity. For example, the loose files to transfer and other manual steps needed to copy or move a pluggable database may be unclear or otherwise error prone for a database administrator.
Furthermore, the infrastructural fabric of a data grid may be a diverse ecosystem with many container databases. Not all container databases may be compatible with a given pluggable database. For example, the release version and patch level of container databases may be so discrepant that portability of a pluggable database between incompatible container databases may be lost or limited.
Furthermore, container databases readily accept installations of pluggable databases, which encourages distributed deployment, replication, horizontal scaling, and bulk deployment throughout a cluster. As such, pluggable databases may benefit from a content format that is durable and eases installation.
Furthermore, a pluggable database may be huge, and a container database may contain thousands of pluggable databases. A content format for pluggable databases should encourage huge datasets.
Furthermore, a copied or moved pluggable database may have a lifecycle of its own that includes subsequent evolution (modification) of content. A pluggable database should accommodate such change.